Population health platform

ABSTRACT

The present disclosure provides systems, methods, and kits for collecting health measurement data and processing the health measurement data to generate alerts and modify patient treatment plans. An example system can be configured to (i) receive data defining a plurality of health sensors; and (ii) generate, based on the data, application logic configured to cause, in response to one user input, a user device to: (a) couple to the plurality of health sensors, thereby establishing communication between the user device and each of the plurality of health sensors, and (b) provide instructions to a user of the user device through an interface of the user device. The instructions can comprise instructions for taking health measurements using the plurality of health sensors.

CROSS-REFERENCE

This application i is a continuation application of U.S. patentapplication Ser. No. 16/932,634, filed on Jul. 17, 2020, which is acontinuation application of U.S. patent application Ser. No. 16/442,277,filed on Jun. 14, 2019, now U.S. Pat. No. 10,748,656, issued Aug. 18,2020, which claims the benefit of U.S. Provisional Patent ApplicationNo. 62/817,486, filed on Mar. 12, 2019, all of which are incorporatedherein by reference in their entirety.

BACKGROUND

Multi-sensor monitoring systems can include a central computing deviceand various peripheral sensors. The central computing device can act asa data aggregator for the peripheral sensors. Conventional multi-sensormonitoring systems can require significant user setup. For example, auser may need to connect the central computing device and eachperipheral sensor to a network, and manually pair each peripheral sensorto the central computing device over the network. This process can beburdensome to users in demographics that are not technologically savvy.Conversely, some multi-sensor monitoring systems may have a streamlinedpairing workflow that is hard-coded to pair a specific set of peripheralsensors to the central computing device. However, hard-coding can resultin an inflexible sensor combination that cannot be dynamically changedacross multiple users of the multi-sensor monitoring system. Changes toa hard-coded system can require full code recompilations and newapplication releases for each user, which can make it difficult to scalethe multi-sensor monitoring system.

Multi-sensor monitoring systems can include health sensor systems. Manyhealth sensor systems may not transform collected data into healthoutcomes for patients. Health sensor systems that use remote monitoringtechnology may rely on human interpretation of health sensor data, orthey may manually inject health sensor data from many verticallyintegrated sensor systems (e.g., distinct oxygen sensing and glucosesensing systems) into a separate third-party analytics provider.Afterwards, the health sensor systems may then provide the output ofthese analytics to service providers (e.g., emergency response services,therapeutics companies, etc.). Currently, no system exists thatagnostically connects health sensor systems to analytics that detectpatient deteriorations and interventional services that address suchdeteriorations. Furthermore, no system performs the aforementioned stepsin a continuous loop to iterate upon its automated decision makingprocesses. The lack of such a system introduces labor inefficiencies andtranslational costs for today's medical providers.

SUMMARY

The present disclosure describes a customizable population healthsystem, and corresponding methods and kits, that can (i) automaticallyconfigure health sensors, (ii) take health measurements using the healthsensors, (iii) automatically manage and process data generated by thehealth sensors, (iv) and automatically utilize processed data togenerate alerts and inform and/or modify treatment or behavioral plans.The population health system can be personalized to each user, and canhorizontally integrate sensors, algorithms, and therapeutic servicesthat can be connected into a custom-tailored portfolio for each user ofthe system.

Specifically, the systems, methods, and kits described in the presentdisclosure can automatically pair, setup, and configure a user-specificcombination of health sensors to a user device on which a healthapplication is installed, thereby establishing wireless communicationbetween the health sensors and the user device, without any requiredinteraction from the user. The system can then instruct the patient totake health measurements using the health sensors and obtain datagenerated by those health sensors with minimal user input.

Data obtained from the sensors can be automatically be transmitted to acloud-based platform of the population health system, where the data canbe processed using a user-specific analytics portfolio that can eitherbe pre-selected by a healthcare provider or automatically selected basedon the system's own artificial intelligence. Once data is processed, thesystem can automatically route select data outputs to the patient, thepatient's healthcare provider, or a user-specific combination of thirdparty service providers (e.g., emergency response services, therapeuticsservices, health coaches, etc.).

As a whole, the system can obtain sensor data and make data-driventherapeutic decisions including the likes of medication titration,enforcing medication adherence, and enforcing behavioral/lifestyleadherence. For each user of the system, system can capture results ofhealth outcomes and continuously iterate upon itself as a user's healthstate changes dynamically.

For patients who do not have a mobile computing device or who strugglenavigating mobile operating systems, the above-mentioned heathapplication can be deployed on an electronic tablet that is shippedalongside the health sensors in a customizable kit. A health careprovider can determine the particular set of health sensors in the kitbased on the patient's medical needs. The health application deployed onthe electronic tablet can be configured with a “workflow” thatcorresponds to the particular set of heath devices in the kit. Theworkflow can be a set of procedures, i.e., processing logic, that cancause the electronic tablet to automatically pair to the heath sensorsover a network without requiring any user interaction, provideinstructions about how to use each of the health sensors to take healthmeasurements, obtain health measurement data generated by those healthsensors, and parlay processed data results (visual and/or audio) back tothe user for education and/or therapeutic feedback. The workflow can beassembled in a modular fashion from pre-defined processing logic. If thehealth care provider prescribes additional health sensors to his or herpatient, the patient can receive another shipment with the additionalhealth sensors. The workflow on the patient's health application can beautomatically reconfigured, e.g., over the cloud, to account for thepatient's new combination of health sensors.

Patients who have their own mobile computing device can instead downloadthe health application from the Apple App Store or the Google PlayStore. Along with a shipment of health sensors prescribed by a healthcare provider, such patients can receive a barcode or a quick response(QR) code that defines the unique combination of health sensors in theshipment. The patient can scan the QR code using the mobile computingdevice, and the health application can configure its workflow based onthe data encoded in the QR code. Alternatively, the health care providercan upload an electronic treatment plan to a cloud-based platform of thepopulation health system. The electronic treatment plan can define theunique combination of health sensors prescribed to the patient by thehealth care provider. The electronic treatment plan can be associatedwith a health profile of the patient to which the health care providerhas access. The health application can synchronize the patient's healthprofile, including the electronic treatment plan, between the platformand the user device. The health application can use the electronictreatment plan to generate a workflow corresponding to the uniquecombination of health sensors prescribed by the health care provider.

The health sensors can include continuous sensors that obtaintime-series data over a period of hours. The continuous sensors can bewearable devices, for example. The health sensors can also includesingle-use sensors that obtain a single health measurement in a finiteperiod of time. The health sensors can include heart rate monitors,blood pressure devices, pulse oximeters, scales, thermometers, glucosemeters, and the like.

The workflow can cause the user device to automatically pair the healthsensors to the user device when the health sensors are (a) on and (b)within range of the user device, thereby establishing wirelesscommunication between the health sensors and the user device. Thewireless communication can be established over a Bluetooth network or aWi-Fi network, for example.

Automatically pairing the health sensors to the health application caninvolve selecting, from a database of pre-defined pairing procedures, apairing procedure for each health sensor in the unique combination. Theautomatic pairing can additionally involve obtaining a universallyunique identifier for each of the health sensors in the uniquecombination, and using the universally unique identifiers to scan andidentify the health sensors. The workflow can also handle setting up andconfiguring secure connections and passkey-based pairing.

The workflow can also cause the user device to provide instructions to apatient through a graphical user interface of the health application inresponse to a user input. The instructions can be instructions fortaking health measurements using the health sensors, e.g., instructionsthat indicate how to use the health sensors. The instructions can beaudible, textual, pictorial, animations, or the like.

The health application can automatically provide instructions for takinga particular health measurement using a particular health sensor afterreceiving valid data for a preceding health measurement, without furtheruser input. In this way, patient interaction with the health applicationcan be minimized. Valid data can be data that falls within a predefinedrange, or it can be data that has a particular characteristic. Thehealth application can also provide control signals to the healthsensors. For example, after determining that a patient is properly usingor wearing a particular health sensor, the health application canautomatically transmit a control signal to the health sensor that causesthe health sensor to take the health measurement. This can furtherminimize patient interaction with both the health application and thehealth sensors.

The health application can obtain health measurement data generated bythe health sensors. The health application can store the healthmeasurement data to the patient's health profile on the platform. Thesystem can automatically monitor the patient's health by inputting thedata into a customizable sequence of algorithms. The sequence ofalgorithms can be automatically changed by the system as a patient'shealth state changes or can be modified by the patient's health careprovider at any time. The outputs of such processing can be extrapolatedinto alerts, essential vitals, and trends. These outputs can be conveyedin real time to health care providers and third party service providers.This can ensure that the patient receives timely medical care in thecase of abnormal health measurements and/or irregular health trends.

The portfolio of algorithms and third party service providers can becustomized for each patient health profile. This can be especiallyuseful for treating patients with multiple comorbidities (chronicdisease states). For example, a patient with chronic obstructivepulmonary disorder (COPD), arterial fibrillation, and hypertension canhave a profile of algorithms that determine likelihood for arrhythmiasand oxygenation/ischemic-related episodes. The service providers forsuch a patient may include emergency responders, health coaches, andcardiologists. A patient with diabetes and chronic heart failure, on theother hand, may have a set of algorithms that detect for the onset ofdiabetic-related edema development and glucose instability. The serviceproviders for such a patient may include endocrinologists, pharmacists,and therapeutics companies.

As a result of horizontally integrating customizable portfolios ofsensors, analytics, and service providers, the system as a whole canmake data-driven therapeutic decisions including the likes of medicationtitration, enforcing medication adherence, and enforcingbehavioral/lifestyle adherence. In the case of medication titration, thesystem can monitor the effects of prescribed medication on a user'schronic illness states. If the prescribed medication for one condition(e.g., diabetes) causes the symptoms of another coexisting condition(e.g., hypertension) to get worse, the system can automatically titratethe user's medication prescription to adjust for these effects. In thecase of medication adherence, the system can detect when patients do nottake their medications and/or perform vital measurements in a timelymanner, and issue visual and/or audio warnings (e.g., notifications,phone calls, etc.) to remind the user to adhere to medicinal protocol.If a user's non-adherence to medication causes a severe drop in theuser's health state, the system can notify third party services to checkin on the user. In the case of lifestyle and behavioral adherence, thesystem can detect behavioral non-adherence (e.g., diabetics eating candyat night or COPD patients not wearing their oxygen masks) and issuewarnings (e.g., through notifications, phone calls, and/or serviceproviders) for patients to rectify behaviors that may damage theirhealth.

The systems, methods, and kits described above can allow patients whoare not technologically savvy to easily obtain health measurement datafrom patient-specific portfolios of health sensors from the comfort oftheir homes, and while requiring minimal user input. Usability studiesshow that the target demographic may not want to setup, pair, andcontrol each health sensor individually. Instead, these patients mayprefer to have minimal interaction with both the health application andthe health sensors. In addition to providing a seamless healthmeasurement experience with minimal user input, the health applicationcan handle end user chaos. For example, the health application canhandle data that is cached on a health sensor when a patient walks outof range of that health sensor during a data upload. The healthapplication can also detect if a patient is using a health sensorimproperly and provide guidance to optimize the patient's usage. Thiscan ensure that the patient takes all measurements in amedically-accurate manner. The ease of use of the system can result ingreater patient adherence to health measurement routines.

Data acquired by the health application can be injected into the rest ofthe system. Upon injection, the system can run the data throughpatient-specific portfolios of algorithms in order to generate processeddata outputs. The procedure of generating such outputs can include, butis not limited to, filtering out excess and/or noisy data, extrapolatinga patient's essential vitals, identifying key trends, and generatingalerts. The generation of alerts can reduce hospitalizations throughtimely intervention. The processed data can then be parlayed topatient-specific portfolios of service providers within the system,which can include the likes of therapeutics services, behavioralservices, and physicians.

As an integrated whole, the system can make important therapeuticinterventions and medicinal titrations to positively impact a patient'shealth outcomes. This is especially beneficial to high risk patientswith multiple comorbidities who need multiple medical sensors to monitortheir health states, carefully balanced medication titrations, andnon-conflicting therapeutic care (one intervention for a disease statedoesn't aggravate another coexisting disease state) in order to preventrehospitalization and/or episodic attacks. To accommodate for thesensitivity and precision required for treating such high risk patients,the system can gather the entire cascade of health results, ranging fromsensor data inception all the way to the health outcomes as a result ofinterventions, and iterate and adjust itself in order to adapt to eachpatient's dynamically changing health state.

The integrated, end-to-end nature of the system can increase throughputand reduce costs for major health care providers.

In an aspect, a population health system can be configured to performoperations comprising: receiving data defining a plurality of healthsensors; and generating, based on the data, a workflow for anapplication on a user device, wherein the workflow is configured tocause the user device to: (i) automatically pair the plurality of healthsensors to the user device when the plurality of health sensors are (a)on and (b) within range of the user device, thereby establishingwireless communication between the plurality of health sensors and theuser device, and (ii) provide instructions to a user through a graphicaluser interface of the application in response to a user input, theinstructions comprising instructions for taking health measurementsusing the plurality of health sensors, wherein the application isconfigured to obtain health measurement data from each of the pluralityof health sensors without additional user input.

In some embodiments, the system comprises a cloud-based platform. Insome embodiments, the operations further comprise storing the healthmeasurements in the cloud-based platform. In some embodiments, thecloud-based platform comprises a health care profile for each of aplurality of users. In some embodiments, receiving data defining aplurality of health sensors comprises receiving an electronic treatmentplan prescribing the plurality of health sensors to a given user of theplurality of users through the cloud-based platform. In someembodiments, the electronic treatment plan is associated with a healthcare profile of the given user on the cloud-based platform. In someembodiments, the health care profile of the given user is accessible toone or more health care providers of the user. In some embodiments, theapplication is configured to communicate an electronic alert to thehealth care provider when any one of the health measurements of thegiven user falls outside of a predefined range.

In some embodiments, receiving data defining a plurality of healthsensors comprises receiving an image of a barcode defining the pluralityof health sensors. In some embodiments, the barcode is a QR code.

In some embodiments, the plurality of health sensors are selected fromthe group consisting of a heart rate monitor, a blood pressure cuff, apulse oximeter, a scale, a thermometer, and a glucose meter. In someembodiments, the plurality of health sensors comprises one or morecontinuous sensors. In some embodiments, the one or more continuoussensors comprise a wearable device. In some embodiments, the pluralityof health sensors comprises one or more spot-check sensors.

In some embodiments, the operations further comprise receiving an orderof the plurality of health sensors, wherein the instructions for takingthe health measurements using the plurality of health sensors areprovided to the user in the order.

In some embodiments, generating the workflow comprises selecting, from aplurality of pre-defined pairing procedures, a pairing procedure foreach the plurality of health sensors. In some embodiments, generatingthe workflow comprises obtaining, from a configuration file, auniversally unique identifier for each of the plurality of healthsensors. In some embodiments, the automatic pairing comprises scanningand identifying the plurality of health sensors defined by the data.

In some embodiments, the workflow is further configured to cause theuser device to transmit control signals to the plurality of healthsensors to control operation of the health sensors during the healthmeasurements.

In some embodiments, the wireless communication is established over aBluetooth network. In some embodiments, the wireless communication isestablished over a Wi-Fi network. In some embodiments, the instructionscomprise animations that indicate how to use the plurality of healthsensors.

In some embodiments, the instructions comprise audible instructions. Insome embodiments, the instructions comprise textual instructions. Insome embodiments, the instructions comprise pictorial instructions. Insome embodiments, the application is configured to provide instructionsfor taking a given heath measurement using a given health sensor afterreceiving valid data for a preceding health measurement. In someembodiments, valid data comprises data falling within a predefinedrange. In some embodiments, valid data comprises data having apredetermined characteristic.

Another aspect of the present disclosure provides a kit comprising aplurality of health sensors and a user device configured to run anapplication, wherein the application is configured to cause the userdevice to perform the operations described above.

Another aspect of the present disclosure provides a method comprisingthe operations described above.

In another aspect, the present disclosure provides a system that canreceive data defining a plurality of health sensors. The system cangenerate, based on the data, application logic configured to cause, inresponse to one user input, a user device to: (a) couple to theplurality of health sensors, thereby establishing communication betweenthe user device and each of the plurality of health sensors, and (b)provide instructions to a user of the user device through an interfaceof the user device. The instructions can comprise instructions fortaking health measurements using the plurality of health sensors.

In some embodiments, the system can obtain health measurement data fromthe user device. The health measurement data can comprise data collectedas a result of the user taking the health measurements. The system candetermine that the health measurement data satisfies an alert criterion.In response to the determination, the system can transmit an alert to ahealth care provider of the user.

In some embodiments, prior to transmitting the alert, the system canclassify the alert as a low-priority alert, a medium-priority alert, ora high-priority alert. Transmitting the alert to the health careprovider can comprise: (i) transmitting a low-priority alert to abehavior intervention service, (ii) transmitting a medium-priority alertto an in-home health service, and (iii) transmitting a high-priorityalert to a primary care physician of the user or an emergency service.

In some embodiments, transmitting the high priority alert to the primarycare physician or the emergency service can comprise transmitting anescalation report to the primary care physician or the emergencyservice.

In some embodiments, the escalation report can comprise a subset of themedical history data for the patient and the health measurement data.

In some embodiments the classifying can comprise obtaining medicalhistory data for the patient and using a trained machine learningalgorithm to process the health measurement data and the medical historydata to generate the classification.

In some embodiments, the trained machine learning algorithm can beselected from the group consisting of: a regression algorithm, a NaïveBayes classifier, a support vector machine, a clustering algorithm, adecision tree algorithm, a random forest, or a neural network.

In some embodiments, receiving data defining the plurality of healthsensors can comprise receiving an electronic treatment plan prescribingthe plurality of health sensors to the user from a primary carephysician of the user.

In some embodiments, receiving data defining the plurality of healthsensors can comprise receiving an image of a barcode defining theplurality of health sensors. The barcode can be a QR code.

In some embodiments, the plurality of health sensors can be selectedfrom the group consisting of a heart rate monitor, a blood pressurecuff, a pulse oximeter, a scale, a thermometer, and a glucose meter.

In some embodiments, the system can receive an order of the plurality ofhealth sensors. The application logic can be configured to provide theinstructions for taking the health measurements in the order.

In some embodiments, generating the application logic can compriseselecting, from a plurality of pre-defined pairing procedures, a pairingprocedure for each of the plurality of health sensors.

In some embodiments, generating the application logic can compriseobtaining, from a configuration file, a universally unique identifierfor each of the plurality of health sensors.

In some embodiments, the coupling can comprise scanning and identifyingthe plurality of health sensors defined by the data.

In some embodiments, the application logic can be further configured tocause the user device to transmit control signals to the plurality ofhealth sensors to control operation of the plurality of health sensorsduring the health measurements.

In some embodiments, the application logic can be a module of a healthapplication installed on the user device. The health application cancomprise a communication interface configured to allow the user tocommunicate with a health care provider.

In some embodiments, the instructions can comprise animations thatindicate how to use the plurality of health sensors.

In some embodiments, the instructions can comprise audible instructions,textual instructions, or pictorial instructions.

In some embodiments, the application logic can be configured to provideinstructions for taking a heath measurement using a health sensor afterreceiving valid data for a preceding health measurement.

In some embodiments, valid data can comprise data falling within apredefined range or data having a predetermined characteristic.

In some embodiments, the application logic can be configured to provideinstructions for re-taking a health measurement after receiving invaliddata for the health measurement.

In some embodiments, the data can comprise a time or a measurementfrequency associated with a respective health sensor of the plurality ofhealth sensors, and wherein the application logic is configured toprovide instructions for taking a health measurement using therespective health sensor at the time or with the measurement frequency.

In some embodiments, the system can store health measurement data fromthe user device on a cloud-based platform. The health measurement datacan comprise data collected as a result of the user taking the healthmeasurements.

In some embodiments, the cloud-based platform can comprise a dashboardconfigured to allow a health care provider to review the healthmeasurement data.

In some embodiments, the system can receive data indicating a validityof the alert from the health care provider and adjust the alertcriterion based on the data indicating the validity of the alert.

Another aspect of the present disclosure provides a kit comprising aplurality of health sensors and a user device configured to run anapplication, wherein the application is configured to cause the userdevice to perform the operations described above.

Another aspect of the present disclosure provides a method comprisingthe operations described above.

Additional aspects and advantages of the present disclosure will becomereadily apparent to those skilled in this art from the followingdetailed description, wherein only illustrative embodiments of thepresent disclosure are shown and described. As will be realized, thepresent disclosure is capable of other and different embodiments, andits several details are capable of modifications in various obviousrespects, all without departing from the disclosure. Accordingly, thedrawings and description are to be regarded as illustrative in nature,and not as restrictive.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in thisspecification are herein incorporated by reference to the same extent asif each individual publication, patent, or patent application wasspecifically and individually indicated to be incorporated by reference.To the extent publications and patents or patent applicationsincorporated by reference contradict the disclosure contained in thespecification, the specification is intended to supersede and/or takeprecedence over any such contradictory material.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity inthe appended claims. A better understanding of the features andadvantages of the present invention will be obtained by reference to thefollowing detailed description that sets forth illustrative embodiments,in which the principles of the invention are utilized, and theaccompanying drawings (also “Figure” and “FIG.” herein), of which:

FIG. 1 schematically illustrates a population health system;

FIG. 2 is a view of a user input feature of a health application of thepopulation health system;

FIG. 3 schematically illustrates a patient-facing layer of the healthapplication;

FIGS. 4 a and 4 b are views of a QR code scanning feature of the healthapplication;

FIGS. 5 a, 5 b, and 5 c are views of health measurement instructionsprovided by the health application;

FIG. 6 schematically illustrates an analytics layer of the populationhealth system;

FIG. 7 schematically illustrates a computer control system that isprogrammed or otherwise configured to implement systems and methodsprovided herein; and

FIG. 8 schematically illustrates a service layer of the populationhealth system.

FIG. 9 is a flow chart of a process for processing alerts and promptingpatient interventions.

FIGS. 10A-10D are images of an example dashboard of the populationhealth system.

FIGS. 11A and 11B are images of an example escalation report generatedby the population health system.

FIG. 12 shows the results of a study that compared the efficacy of thepopulation health system with various other single-sensor platforms.

FIG. 13 shows how the alert processing system results in efficienciesfor customers.

DETAILED DESCRIPTION

While various embodiments of the invention have been shown and describedherein, it will be obvious to those skilled in the art that suchembodiments are provided by way of example only. Numerous variations,changes, and substitutions may occur to those skilled in the art withoutdeparting from the invention. It should be understood that variousalternatives to the embodiments of the invention described herein may beemployed.

The present disclosure describes customizable population health system,and corresponding methods and kits, that can (i) automatically configurehealth sensors, (ii) take health measurements using the health sensors,(iii) manage data generated by the health sensors, (iv) and use the datato generate or modify treatment or behavioral plans. Specifically, thesystems, methods, and kits described in the present disclosure can allowa patient to automatically pair a unique combination of health sensorsto a user device on which a health application is installed, therebyestablishing wireless communication between the health sensors and theuser device. The health application can instruct the patient to takehealth measurements using the health sensors and obtain data generatedby heath sensors with minimal user input.

FIG. 1 schematically illustrates a population health system. A patientcan use the population health system to: (i) take health measurementsusing health sensors; (ii) obtain, store, and manage data generated bythe health sensors; and (iii) use the data to generate alerts or modifytreatment or behavioral plans. The population health system can beconfigured to require minimal user input at all stages of the healthmeasurement process. For example, the population health system can beconfigured to automatically setup, pair, and control the health sensors.The population health system can also be configured to automaticallyinstruct a patient how to take health measurements and in which order totake those health measurements. Finally, the population health systemcan be configured to automatically obtain data generated by the healthsensors and transmit that data to a platform accessible to a health careprovider.

The population health system can include a user device 102. The userdevice 102 can be any electronic device capable of communicating withother electronic devices over a network, e.g., a Bluetooth network, aWi-Fi network, the Internet, or the like. For example, the user device102 can be a laptop or desktop computer, an electronic tablet, asmartphone, a smartwatch, or the like. In some implementations, the userdevice 102 can be a patient's personal device. In other implementations,the user device 102 can be provided to the patient along with a shipmentof health sensors.

The user device 102 can run a health application 104. The healthapplication 104 can be an HTML, document rendered by a web-browser,JavaScript code or Java code, or dedicated software, e.g., an installedapplication. The health application 104 can cause the user device 102 toautomatically pair to, i.e., establish a wireless connection with,health sensors 106 a-106 n over a network 108. Thereafter, the healthapplication 104 can wirelessly communicate with the health sensors 106a-106 n. For example, the health application 104 can transmit controlinstructions to the health sensors 106 a-106 n and obtain healthmeasurement data from the heath sensors 106 a-106 n.

The health application 104 can also be configured to provideinstructions to the patient about how to take health measurements usingthe health sensors and in which order to take the health measurements.In response to a user input, the health application 104 can provideinstructions to the patient about how to take a health measurement usinga particular health sensor. The user input can be a tap on a capacitivetouch screen, a mouse-click, or a voice command, to name a few examples.FIG. 2 is a view of a user input feature of the health application 104.As indicated in FIG. 2 , a patient can “Tap the icon to add ameasurement.”

The instructions can be audible, textual, pictorial, animated, or somecombination of these. The health application 104 can includeconfigurable settings that allow a patient to specify the format inwhich he or she prefers to receive instructions. For example, a patientwho is hard-of-hearing may choose to receive visual instructions overaudible instructions.

The instructions can indicate which device to use to take the healthmeasurement. The health application 104 can cause the user device 102 todisplay an image of the health sensor, to say the name of the healthsensor, or to describe what the health sensor looks like. The healthapplication 104 can determine that the patient identified and picked upthe correct health sensor by detecting motion or a change in position ofthe health sensor.

The health application 104 can then cause the user device 102 to provideinstructions to the patient regarding how the patient should positionthe health sensor in order to take a proper health measurement. Forexample, if the health sensor is a blood pressure device, the healthapplication 104 can cause the user device 102 to provide instructionsthat indicate that the patient should position the blood pressure cuffon his or her upper right arm. As another example, if the health sensoris a pulse oximeter, the health application 104 can cause the userdevice 102 to provide instructions that indicate that the patient shouldposition the pulse oximeter on his or her left index finger.

The health sensor can include position sensors that collect dataregarding the location of the health sensor relative to the patient'sbody. The health sensor can transmit that data to the health application104, which can interpret the data to determine whether the heath sensorshould be adjusted relative to its current position, or whether it ispositioned properly on the patient's body. If the health sensor is notpositioned properly, the health application 104 can cause the userdevice 102 to provide additional, corrective instructions. For example,if the health sensor is a blood pressure device, the health application104 can cause the user device 102 to provide instructions that indicatethat the patient should adjust the position of the blood pressure cuffon his or her arm.

After the health application 104 determines that the health sensor isproperly positioned with respect to the patient's body, the healthapplication can transmit control instructions to the health sensor, ifnecessary. For example, if the health sensor is a blood pressure device,the health application 104 can cause the user device 102 to transmit acontrol signal to the cuff of the blood pressure device that can causethe cuff to inflate. In some cases, the health application 104 may nottransmit control signals to the health sensor. For example, if thehealth sensor is a heart rate monitor, the heart rate monitor may begincollecting valid data as soon as it is correctly positioned on thepatient's body, and it may not need an external control signal tooperate. Likewise, passive devices such as scales and thermometers maybegin collecting valid data as soon as they are correctly positioned.

While the health sensor obtains data from the patient, the healthapplication 104 can cause the user device 102 to indicate the progressof the health measurement. The indication can be a visual indication,e.g., a progress bar or a textual percentage, or an audible indicationof the same.

The health sensor can transmit resultant health measurement data to theuser device 102. The health application 104 can determine if the data isvalid. Valid data can be data that falls within a predefined range. Forexample, a valid heart rate may be between 20 beats/minute and 220beats/minute. If the data falls outside the predefined range, the healthapplication 104 may determine that the health sensor was incorrectlypositioned or used, and the health application 104 may instruct the userto take the health measurement again. Valid data can also be data thathas a particular characteristic. For example, if the health sensor is ascale, the health application 104 may expect to receive a single datapoint indicating the patient's measured weight. If the received data isinstead time-series data with multiple data points, the healthapplication 104 may determine that the data is invalid, e.g., becausethe patient used the incorrect health sensor.

When the health application 104 determines that it has received validdata for the health measurement, the health application 104 can causethe user device 102 to provide instructions for taking a second healthmeasurement using a second health sensor. The process described abovecan be repeated for each of the health sensors in the patient's uniquecombination of health sensors.

In some cases, instructions for taking a particular health measurementmay be provided at a particular time of day, e.g., after the patient haseaten a meal. In such cases, the health application 104 can notify thepatient to take the health measurement at that time. The healthapplication 104 can also remind the patient to take measurements thatare overdue.

The health application 104 can immediately transmit valid data that itreceives from a health sensor to a platform 110. The platform 110 can beimplemented on the cloud and can store and process patient data andprovide health care professionals access to the data. The platform 110and portions thereof will be described in greater detail in reference toFIG. 6 .

FIG. 3 schematically illustrates a patient-facing layer of the healthapplication described herein. The patient-facing layer can include aguided workflow engine 300 that can, using a portfolio of sensorintegration modules 310, (i) connect the health sensors to the userdevice on which the health application is installed, (ii) providepatient instructions as described in detail in reference to FIG. 1 ,(iii) control operation of the health sensors, (iv) transmit andsynchronize data between the health sensor, the health application, andthe analytics layer, and (v) handle errors that occur at any point inthe process.

The portfolio of sensor integration modules 310 can include a sensorintegration module for each health sensor in the population healthsystem. Each sensor integration module can include procedures forperforming functions (i), (ii), (iii), (iv), and (v) above. For example,the sensor integration module for sensor A can include pre-definedprocedures that cause the user device to (i) pair sensor A to the userdevice, (ii) provide visual or audible instructions about how to usesensor A, (iii) control operation of sensor A after it is properlypositioned on the patient's body, (iv) receive health measurement andother data from health sensor A and transmit that data to the platform,and (v) handle any errors that occur while the patient uses sensor A.Each of these functions is described in greater detail below.

The guided workflow engine 300 can select from the portfolio 310 theparticular sensor integration modules that correspond to the healthsensors prescribed to the patient by a health care provider. Aspreviously mentioned, the health sensors prescribed to a patient can bedefined in an electronic health plan or a QR code. The guided workflowengine 300 can read the electronic health plan or the QR code andintegrate the corresponding sensor integration modules into the workflowof the application. FIGS. 4 a and 4 b are views of a QR code scanningfeature of the health application.

In some implementations, the electronic health plan or the QR code candefine an order of the prescribed health sensors. In suchimplementations, in addition to selecting the sensor integration modulesfrom the portfolio 310, the guided workflow engine 300 can arrange thesensor integration modules in the order. This can ensure that thepatient takes health measurements in the prescribed order. Theelectronic health plan or the QR code can also define a measurementfrequency for each health sensor, or a time of day that each healthsensor should be used. The guided workflow engine 300 can incorporatethese conditions into the workflow for the health application, e.g., byproviding health measurement instructions to the patient at the definedfrequencies or particular time of day.

The ordered combination of sensor integration modules (and the frequencyand time of day at which the sensor integration modules are executed)defines the workflow for a given instance of the health application. Theworkflow can be activated by an initial user input in the healthapplication. In some cases, the initial user input is the only inputrequired to take all prescribed health measurements. In the workflowillustrated in FIG. 3 , the initial user input can trigger execution ofsensor integration module B. Execution of sensor integration module Bcan cause the user device on which the health application is installedto pair to sensor B. Next, sensor integration module B can cause theuser device to provide instructions to the patient about how to usesensor B, control operation of sensor B, receive health measurement datafrom sensor B, and transmit that data to the platform. Thereafter,sensor integration module B can pass control to sensor integrationmodule D, which can perform corresponding functions for sensor D. Thisprocess can be repeated until the entire workflow is complete. Thefunctions that each sensor integration module can perform are greaterdetail below.

Health Sensor Pairing

The sensor integration module for a particular health sensor can includea procedure, i.e., processing logic or code, for automatically pairingthe health sensor to the user device on which the health application isinstalled when the health sensor is (i) powered on and (ii) within rangeof the user device.

The sensor integration module can receive a request for a list of healthsensors that are visible to the user device. The request can be a userinput. The user input can be, for example, a request to begin a healthmeasurement session.

The request can cause the sensor integration module to activate acommunication interface, e.g., a Bluetooth communication interface or aWi-Fi communication interface, on the user device. Using thecommunication interface, the sensor integration module can scan fordevices in the vicinity that use the same communication interface. Thesensor integration module can obtain a list of devices that are visibleto the user device. The list of devices can include an identifier, e.g.,a MAC address or name, for each of the devices in the list. The sensorintegration module for the health sensor can compare the identifiers inthe list to a known identifier for the health sensor. If the sensorintegration module identifies a match, it can send a connection requestto the health sensor. The connection request can include authenticationinformation, e.g., a password, for the health sensor. The user deviceand the health sensor can establish a cryptographically secureconnection by sharing a secure link key. The health sensor and the userdevice can each store the secure link key. Once the link key isgenerated, an authenticated Asynchronous Connectionless (ACL) linkbetween the devices can protect exchanged data against eavesdropping.This can ensure that sensitive health measurement data is not stolen.The health sensor and the user device can store the secure link keyindefinitely or for a predetermined period of time so that the healthsensor and the user device can pair more quickly during subsequenthealth measurement sessions.

Patient Instructions

The sensor integration module for a health sensor can also includeprocedures that, when executed, cause the user device to provideinstructions about how to use the health sensor. These procedures can beexecuted after the health sensor is successfully paired to the userdevice. The user device can provide the instructions through a graphicaluser interface. For example, the user interface can display animations,textual instructions, or a video about how to use the health sensor. Thevisual instructions can be accompanied by audible instructions.

FIGS. 5 a, 5 b, and 5 c are views of health measurement instructionsprovided by the health application. FIG. 5 a is a view of healthmeasurement instructions for a pulse oximeter, which is a device thatcan be used to measure a patient's blood oxygen levels. The instructionscan include (i) the name of the health measurement (“Pulse Ox”), (ii) animage or animation demonstrating how to use the pulse oximeter on afinger, (iii) textual instructions that indicate that the patient should“hold still while this process completes,” and (iv) a completionpercentage for the process.

FIG. 5 b is a view of health measurement instructions for a bloodpressure device. The instructions can include (i) the name of the healthmeasurement (“Blood Pressure”), (ii) an image or animation demonstratinghow to position the blood pressure cuff on an arm, (iii) textualinstructions that indicate that the patient should “hold your arm stillwhile this process completes,” and (iv) a message indicating that themeasurement is in progress.

FIG. 5 c is a view of health measurement instructions for a scale. Theinstructions can include (i) the name of the health measurement(“Weight”), (ii) a picture of the device, (iii) textual instructionsindicating that the patient should “wait while this process completes,”and (iv) a message indicating that the measurement is in progress.

The instructions can be more thorough if the health sensor is complex touse or unfamiliar to many patients. To that end, the instructions caninclude a number of steps. The user device may provide instructions fora particular step only after the preceding step is complete. Forexample, if the health sensor is a blood pressure device, the userdevice may first instruct the patient to place the blood pressure cuffon his or her arm. The user device may provide instructions for a nextstep only after the patient has properly positioned the blood pressurecuff on his or her arm. The sensor integration module can determine ifthe patient properly positioned the blood pressure cuff on his or herarm by communicating with the blood pressure cuff over the network. Theblood pressure cuff can have sensors that can detect the position of theblood pressure cuff relative to the patient's arm, and the bloodpressure cuff can transmit a signal to the health application thatindicates whether or not the cuff is properly positioned. The sensorintegration module may only proceed to provide instructions for the nextstep in the process if the signal indicates that the blood pressure cuffis properly positioned on the patient's arm.

Alternatively, the instructions can be simple if the health sensor iseasy to use and generally familiar to patients. For example, if thehealth sensor is a scale, the instructions may simply show an image of ascale.

Heath Sensor Operation

The sensor integration module for a health sensor can also includeprocedures that, when executed, control operation of the health sensor.The sensor integration module can cause the user device to transmitcontrol signals to the health sensor when particular conditions are met.For example, if the health sensor is a scale, the sensor integrationmodule can transmit a signal to the scale that causes the scale tomeasure the patient's weight when a force is applied to the scale. Asanother example, if the health sensor is a blood pressure device, thesensor integration module can transmit a signal to the blood pressurecuff that causes it to inflate when the sensor integration moduledetermines that the blood pressure cuff is properly positioned on thepatient's arm. By controlling operation of the health sensor, the sensorintegration module can minimize user input that is required to operatethe health sensor.

In some cases, the health sensor may not need to receive control signalsfrom the user device, but can instead operate independently. Forexample, a heart rate monitor may begin collecting data as soon as it isturned on.

The health application can initiate pairing, provide health measurementinstructions to the patient, and operate the health sensors in responseto a single user input in the health application. In some cases, nofurther patient interaction with the health application may be required.

Data Synchronization & Error Handling

The sensor integration module can also handle communication between theuser device and the health sensor, and between the health sensor and theplatform. As previously mentioned, the sensor integration module cancause the user device to transmit control signals to the health sensor.The sensor integration module can also include processing logic forrequesting data from the health sensor. The data can include data aboutwhether the health sensor is being used properly, and data generated asa result of taking a health measurement, e.g., a blood pressure, a bloodoxygen level, or a weight.

In some cases, a patient may move the user device out of communicationrange of the health sensor while health measurement data is beingtransmitted to the user device. The sensor integration module candetermine that the received data is incomplete, and can transmit arequest to the health sensor to send the remaining data once the userdevice is again within range and paired to the health sensor.

In some cases, a patient may use a health sensor incorrectly, which maycause the sensor integration module to receive invalid data. The sensorintegration module can determine that particular data is invalid bycomparing it to an expected format, range, or characteristic of thedata. If the data does not satisfy the expected format, range, orcharacteristic, the sensor integration module can cause the user deviceto provide new or revised instructions to the patient about how to usethe health sensor.

The sensor integration module can also handle communication between theuser device and the platform, on which the health measurement data maybe permanently stored.

FIG. 6 schematically illustrates an analytics layer of the populationhealth system described herein. The analytics layer can be implementedon the platform 110 described in reference to FIG. 1 . The analyticslayer can include an analytics integration engine 600. The analyticsintegration engine 600 can be configured to modularly integrate anycombination of third-party analytics and algorithms to create customizedhealth and behavioral guidance for a patient. Examples of such guidancecan include medicinal methods (e.g., optimized insulin dosage amounts orarterial fibrillation detection) or behavioral methods (e.g., optimizedsleep patterns, caloric intake, or exercise habits). Like the guidedworkflow engine 300, the analytics integration engine 600 can selectfrom a portfolio of analytics integration modules 610 analyticsintegration modules that correspond to analytics selected by a healthcare provider for the patient. Alternatively or additionally, a machinelearning model trained on data from the patient-facing layer canautomatically select appropriate analytics integrations modules. Theanalytics integration modules can be inserted and reordered in theanalytics workflow in real-time. The analytics integration engine 600can receive data from the patient-facing layer to inform the third-partyanalytics and algorithms. For example, a third-party dieting applicationcan use weight data from the patient-facing layer to adjust mealrecommendations. The analytics layer and the patient-facing layer can becombined to form a complete end-to-end solution that can produceoutcomes that adapt to each patient's changing health state. Theoutcomes can then be relayed to care providers, health coaches, and thepatients themselves. The ability of the analytics integration engine 600to combine any combination of in-house or third party analytics modulescan ensure that a large combination of methods are simulated, tested,and optimized to ensure maximum effect on patient outcomes.

FIG. 8 schematically illustrates a service layer of the populationhealth system described herein. The service layer, like the analyticslayer, can be implemented on the cloud-based platform 110 described inreference to FIG. 1 . In general, the service application layer canreceive processed health measurement data from the analytics layer,determine whether the processed health measurement data satisfies analert criterion, and alert a health care service if the data doessatisfy the alert criteria. “Health care services” as used herein caninclude emergency services, e.g., ambulance services, or a patient'sprimary care physician, pharmacist, nutritionist, or exercise coach, toname a few examples.

The service layer can include a services integration engine 800. Theservices integration engine 800 can select appropriate service modulesfor a particular patient from a portfolio of service modules 810. Theservice modules can receive processed health measurement data, e.g.,analytics outputs, from the analytics layer, determine whether theprocessed health measurement data satisfies an alert criterion, andalert the corresponding health care service if the data does satisfy thealert criteria.

In an example, a patient may use the patient-facing layer of the healthapplication and an electrocardiograph to measure the patient's heartactivity. The health application can transmit the raw data to theanalytics layer, where a heart activity algorithm can analyze the rawdata. The services integration module 800 can provide the output of thealgorithm to one or more service modules, e.g., a service module for anambulance service and a service module for the patient's primary carephysician. If the output of the algorithm satisfies an alert criterionfor a particular service module, that service module can alert thecorresponding service. The service modules can have different alertcriteria. For example, the alert criterion for a service module for anambulance service may correspond to an analytics output that indicates alife-threatening abnormality. In the case of a heart activity algorithm,such an analytics output may be a particular confidence that a heartattack is occurring. On the other hand, the alert criterion for aservice module for the patient's primary care physician may correspondto an analytics output that indicates a non-life-threateningabnormality. In the case of a heart activity algorithm, such ananalytics output may be a particular confidence that the patient hasarterial fibrillation, but that a heart attack is not presentlyoccurring).

The services integration engine 800 can use machine learning methods toselect appropriate service modules for a patient. Initially, servicemodules may be selected or verified by a human. In time, however, theservice layer can aggregate analytics outputs and data about servicealerts that were generated as a result of the analytics outputs. Ahealth care provider can determine, based on the health analyticsoutputs, whether the service alerts were actually necessary. This datacan serve as training data for a supervised machine learning model. Themachine learning model can determine that particular services are or arenot necessary for a particular patient and add or remove those servicesfrom the patient's instance of the service layer.

FIG. 9 is a flow chart of an example process for processing alerts andprompting patient interventions. The process can be performed by theanalytics layer described in reference to FIG. 6 .

The analytics layer can receive health measurement data from a patient'suser device (900). The health measurement data can indicate thepatient's heart rate or rhythm, blood pressure, blood oxygen level, bodyweight, body temperature, or blood sugar level, for example.

The analytics layer can determine whether the health measurement datasatisfies an initial alert criterion (910). The initial alert criterioncan be a minimum or maximum value. For example, the initial alertcriterion can be a minimum or maximum heart rate, a minimum or maximumblood pressure, a minimum or maximum blood oxygen level, a minimum ormaximum body weight, a minimum or maximum body temperature, or a minimumor maximum blood sugar level. In some cases, the initial alert criterioncan be the existence or occurrence of a particular feature in the healthmeasurement data (e.g., a particular heart rhythm). Alternatively, theinitial alert criterion can be a magnitude or percent deviation from abaseline health measurement for the patient.

The initial alert criterion can be an alert criterion that is applicableto the general population. For example, the initial alert criterion forblood oxygen level can be a blood oxygen level below which the medicalcommunity generally recognizes as unsafe. Alternatively, the initialalert criterion can be an alert criterion that is applicable to asub-population to which the patient belongs. For example, if the patienthas chronic obstructive pulmonary disorder (COPD), the initial alertcriterion for blood oxygen level for the patient can be a blood oxygenlevel below which the medical community recognizes as being unsafe forpatients with COPD. Patients with COPD may have lower safe blood oxygenlevels than patients without COPD. The initial alert criterion caninstead be patient-specific. For example, a patient that typically hasblood oxygen levels below the normal range can have a lower initialalert criterion. The use of different initial alert criteria fordifferent sub-populations and patients can reduce the generation offalse alerts.

The initial alert criterion can be static as described above, or it canbe dynamic. For example, an algorithm can determine the initial alertcriterion in real-time based on the patient's previous healthmeasurements, diagnostic and medication history, current health state,current diet and exercise levels, the validity of previous alerts asdetermined by a health care professional or interventional service, andother factors. The algorithm can be a machine learning algorithm.

If the health measurement data does satisfy the initial alert criterion,the analytics layer can generate an initial alert (920). Generating theinitial alert can involve pushing a record of the health measurementdata to a dashboard on the analytics layer. FIG. 10A is an image of sucha dashboard. The dashboard can be a graphical user interface viewable byhuman agents that can assess whether the alert is true or false, and ifthe alert is true, the severity of the alert. The human agents can betrained medical professionals (e.g., health coaches, technicians, orboard-certified nurses or doctors). The record of the health measurementdata that is pushed to the dashboard can include the health measurementitself, the time the measurement was taken, and previous healthmeasurements for the patient. The dashboard can allow the human agent toclassify the alert as true or false and take follow-up actions if thealert is classified as true. The dashboard can also have a communicationinterface that allows the human agent to contact the patient through thehealth application. The human agent can ask the patient, for example, totake the health measurement again or whether any extenuatingcircumstances may have affected the health measurement. The patient,using a corresponding communication interface in the health application,can confirm that he or she will take the health measurement again orexplain any extenuating circumstances. For example, the patient mayexplain that his heart rate is high because he was exercisingimmediately prior to the health measurement; that his blood sugar ishigh because he recently ate; or that his blood oxygen level is lowbecause he briefly stopped using his oxygen machine to use the restroom.The human agent can use this information is determining whether thealert is true or false. The dashboard will be described in greaterdetail below.

After the analytics layer generates an initial alert, the analyticslayer, a human agent or both can determine whether the alert is true orfalse (930). In some cases, the analytics layer can resolve alertswithout input from a human agent. The analytics layer can determine, forexample, that although the health measurement data for the patientsatisfied an initial alert criterion for the general population, thedata did not satisfy a less restrictive secondary alert criterion forthe patient. Similarly, the analytics layer may determine that althoughthe health measurement data for the patient satisfied an initial alertcriterion, the data did not depart a sufficient amount from thepatient's baseline health measurement to constitute a true alert. Insuch a case, the analytics layer may again resolve the alert withoutinput from a human agent.

The analytics layer can transmit a communication to the patient's userdevice to ask for additional information. For example, if the analyticslayer detects an anomaly or error in the health measurement data, theanalytics layer can transmit a message to the patient's user device thatasks the patient to retake the health measurement. Alternatively, theanalytics layer can reconfigure the health application workflow inreal-time to simplify the health measurement process for the patient.

In some cases, the analytics layer can perform an initial assessment ofthe alert, but the platform may require that a human agent review thealert before it can be resolved. In still other cases (e.g., when thealert relates to a critical health measurement), a human agent may beprompted to perform a first review of the alert. The platform canautomatically prioritize alerts and assign alerts to particular humanagents.

Human agents can review initial alerts on the dashboard depicted in FIG.10A. The dashboard can display alerts in a table. Each row in the tablecan be a different alert. The columns in the table can depict differentinformation about each alert, e.g., a patient name or patient ID, alertID, a summary of the health measurement that resulted in the alert andprevious health measurements for the patient, the date and time thehealth measurement was taken, the human agent to which the initial alertwas assigned, whether the alert has been resolved, and the status of theresolved alert. An alert can include a link to the patient's profile onthe dashboard. The profile can include the patient's medical history andprevious health measurement data. The previous health measurement datamay be depicted in a graph so that the human agent can easily see thepatient's progress over time. The dashboard can allow the human agent torecord notes about the alert, resolve the alert as either true or false,and if true, escalate the alert to a health care provider (FIG. 10B andFIG. 10C). Notes and actions taken by the human agent can be preservedto create an audit trail. The notes and actions can also be incorporatedinto the patient's electronic health record (EHR).

If the analytics layer or a human agent determines that the initialalert is true, the analytics layer can automatically pull the patient'sEHR into the platform (940). FIG. 10D is an image of a patient's EHR asit might be displayed on the platform.

Using the health measurement data that resulted in the alert, thepatient's previous health measurements, and the patient's EHR, theanalytics layer or a human agent can classify the alert as a low,medium, or high priority (950).

The analytics layer can use a machine learning algorithm to classify thealert as low, medium, or high priority. The machine learning algorithmcan receive as input the health measurement data that caused the alertto be generated, the patient's previous health measurement data, anddata from the patient's EHR, e.g., clinical test results, medicationhistory, family history, diagnoses, and the like. The machine learningalgorithm can be trained to accurately classify alerts based on theseinputs. The machine learning algorithm can be trained to recognizelatent features (e.g., correlated inputs) that result in a particularclassification.

The training data for the machine learning algorithm can be previoushealth measurements that resulted in true alerts and the actual priorityof those alerts as determined by a health care professional, along withother features of the patient's medical history. Such training data canbe used to tune the parameters of the machine learning model to moreaccurately predict the priority of future alerts. The machine learningalgorithm can be trained on data from the general population, data froma sub-population to which to the patient belongs, or data from thepatient alone. In some cases, the machine learning model can be trainedon data from the general population but conditioned on data from thepatient.

The machine learning algorithm can be a supervised machine learningalgorithm or an unsupervised machine learning algorithm. The machinelearning algorithm can be a regression algorithm, a Naïve Bayesclassifier, a support vector machine, a clustering algorithm, a decisiontree algorithm, a random forest, or a neural network.

Neural networks may be well-suited to classify alerts as low, medium, orhigh priority. Neural networks are machine learning models that can usemultiple layers of operations to predict one or more outputs from one ormore inputs. The input layer of a neural network can receive one or morefeatures that may be indicative of the desired output. Neural networkscan include one or more hidden layers situated between the input layerand an output layer. The nodes of the input layer can be connected tothe nodes of the first hidden layer, and the nodes of the first hiddenlayer can additionally be connected to nodes in a subsequent hiddenlayer or the output layer. Each connection can have a weight. A node'soutput (i.e., activation) can be based on the inputs to the node (i.e.,the activations in the previous layer) and the weights of the incomingconnections. The connections and weights can define a complex function.The output layer of a neural network can have one node for each of thepossible outputs (e.g., classifications). The relative activations ofthe nodes in the output layer can represent the predictedclassification.

Training a neural network can involve adjusting the connection weightsuntil the neural network accurately predicts outputs at an acceptablerate. Adjusting the connection weights can involve providing inputs tothe neural network for which an output is known. The predicted outputgenerated by the neural network can be compared to the known output tocompute the value of an error-function. The error can be“back-propagated” through the network. That is, the weight of eachconnection can be adjusted to reduce the value of the error function bysome small amount. After repeating this process for a sufficiently largenumber of training cycles, the neural network can converge to some statewhere the error of the calculations is small.

Additionally or alternatively, a human agent can review and classify thetrue alert as being a low, medium, or high priority alert. In somecases, one of the machine learning algorithms described above can makean initial classification. If the initial classification is medium orhigh, a human agent can review the alert to confirm that theclassification is correct and expedite patient intervention.

If the analytics layer and/or a human agent determines that the truealert is a low-priority alert, the analytics layer can transmit thealert to an in-house medical professional or a behavioral interventionservice (e.g., health coach) (960). The in-house medical professional orhealth coach can then reach out to the patient (e.g., via phone, text,email, or through application) to address the cause of the alert.

If the analytics layer and/or a human agent determines that the truealert is a medium-priority alert, the analytics layer can transmit thealert to a health care service that can conduct an in-home visit withthe patient (970).

If the analytics layer and/or a human agent determines that the truealert is a high-priority alert, the analytics layer can transmit thealert directly to the patient's primary care physician or an emergencyservice (980). In addition to escalating the alert, the analytics layercan automatically generate and transmit an escalation report to thepatient's primary care physician (990). FIG. 11A is an image of a firstpage of an example escalation report. The escalation report can includethe patient's name, address, contact information, height and weight,date of birth and age, medication history, and diagnostic history. Theescalation report can also include a summary of the health measurementthat caused the alert to be generated (“Patient first diastolic value ofthe day was 112 mmHG, and repeat measurement yielded 114 mmHG.”) Theescalation report can also include a summary of an investigationconducted by a human agent, if applicable, (“Patient's blood pressurehas been going up steadily since medication change last week.”) and anyfeedback that the patient provided about his or her health state(“Feeling hungrier and dizzier since last week—more tired as well. Drank3 beers last night.”) The escalation report may also include a graph ofthe relevant health measurement over time (FIG. 11B). In some cases, thegraph may include a marker that indicates the occurrence of an event,e.g., a hospitalization or a medication change. The marker can addcontext the patient's measurements. The patient's primary care physiciancan use this report to quickly and easily make health care decisions.The analytics layer can automatically generate the escalation report byintegrating data stored on the platform with data from the patient'sEHR.

The analytics layer can transmit a record of the alert and thesubsequent intervention to the patient's EHR (995). The analytics layercan also generate and transmit tasks, e.g., future appointments ortests, to the patient's EHR. Escalating alerts and interventions in thistiered-fashion can reduce health care costs and hospitalizations.

After the intervention is complete, a human agent can follow-up with thepatient through the health application to ensure that proper treatmentwas provided (997). If necessary, the human agent can re-escalate thealert to a health care provider.

FIG. 12 shows the results of a study that compared the efficacy of thepopulation health system described herein with various othersingle-sensor platforms. For each patient, the population health systemwas configured to have a heart rate sensor, a pulse oximeter, a scale,and a blood pressure device, while the single-sensor platforms wereconfigured to have only a pulse oximeter. Only 30% of patients using thevarious other single-sensor platforms were able to take unassistedmeasurements, while 94% of patients using the population health systemdescribed herein were able to take unassisted measurements. This datademonstrates how the guided workflow in the health application canresult in greater patient adherence to health measurement routines. As aresult of this increased adherence, the population health system canreduce hospitalizations of patients by 78% due to early intervention.

FIG. 13 shows how the alert processing system described in reference toFIG. 9 results in efficiencies for customers. The population healthsystem may generate approximately 85 initial alerts per 100 patients perweek. The initial alerts may be based on customer-defined metrics thatare very restrictive. The population health system may classifyapproximately 70 of the 85 initial alerts as false, leavingapproximately 15 true alerts. The population health system may classifyapproximately 12 of the 15 true alerts as low-priority ormedium-priority alerts that can be handled without intervention by thepatients' primary care physicians. This leaves only approximately threealerts that are escalated to the patients' primary care physicians. Thisalert filtering and tiered-escalation process can save customers timeand money and ensure early intervention for alerts that are trulycritical.

Computer Control Systems

The present disclosure provides computer control systems that areprogrammed or otherwise configured to implement methods of thedisclosure. FIG. 7 shows a computer system 701 that is programmed orotherwise configured to control the user devices or health sensorsdescribed in this disclosure.

The computer system 701 includes a central processing unit (CPU, also“processor” and “computer processor” herein) 705, which can be a singlecore or multi core processor, or a plurality of processors for parallelprocessing. The computer system 701 also includes memory or memorylocation 710 (e.g., random-access memory, read-only memory, flashmemory), electronic storage unit 715 (e.g., hard disk), communicationinterface 720 (e.g., network adapter) for communicating with one or moreother systems, and peripheral devices 725, such as cache, other memory,data storage and/or electronic display adapters. The memory 710, storageunit 715, interface 720 and peripheral devices 725 are in communicationwith the CPU 705 through a communication bus (solid lines), such as amotherboard. The storage unit 715 can be a data storage unit (or datarepository) for storing data. The computer system 701 can be operativelycoupled to a computer network (“network”) 730 with the aid of thecommunication interface 720. The network 730 can be the Internet, aninternet and/or extranet, or an intranet and/or extranet that is incommunication with the Internet. The network 730 in some cases is atelecommunication and/or data network. The network 730 can include oneor more computer servers, which can enable distributed computing, suchas cloud computing. The network 730, in some cases with the aid of thecomputer system 701, can implement a peer-to-peer network, which mayenable devices coupled to the computer system 701 to behave as a clientor a server.

The CPU 705 can execute a sequence of machine-readable instructions,which can be embodied in a program or software. The instructions may bestored in a memory location, such as the memory 710. The instructionscan be directed to the CPU 705, which can subsequently program orotherwise configure the CPU 705 to implement methods of the presentdisclosure. Examples of operations performed by the CPU 705 can includefetch, decode, execute, and writeback.

The CPU 705 can be part of a circuit, such as an integrated circuit. Oneor more other components of the system 701 can be included in thecircuit. In some cases, the circuit is an application specificintegrated circuit (ASIC).

The storage unit 715 can store files, such as drivers, libraries andsaved programs. The storage unit 715 can store user data, e.g., userpreferences and user programs. The computer system 701 in some cases caninclude one or more additional data storage units that are external tothe computer system 701, such as located on a remote server that is incommunication with the computer system 701 through an intranet or theInternet.

The computer system 701 can communicate with one or more remote computersystems through the network 730. For instance, the computer system 701can communicate with a remote computer system of a user. Examples ofremote computer systems include personal computers (e.g., portable PC),slate or tablet PC's (e.g., Apple® iPad, Samsung® Galaxy Tab),telephones, Smart phones (e.g., Apple® iPhone, Android-enabled device,Blackberry®), or personal digital assistants. The user can access thecomputer system 701 via the network 730.

Methods as described herein can be implemented by way of machine (e.g.,computer processor) executable code stored on an electronic storagelocation of the computer system 701, such as, for example, on the memory710 or electronic storage unit 715. The machine executable or machinereadable code can be provided in the form of software. During use, thecode can be executed by the processor 705. In some cases, the code canbe retrieved from the storage unit 715 and stored on the memory 710 forready access by the processor 705. In some situations, the electronicstorage unit 715 can be precluded, and machine-executable instructionsare stored on memory 710.

The code can be pre-compiled and configured for use with a machinehaving a processer adapted to execute the code, or can be compiledduring runtime. The code can be supplied in a programming language thatcan be selected to enable the code to execute in a pre-compiled oras-compiled fashion.

Aspects of the systems and methods provided herein, such as the computersystem 701, can be embodied in programming. Various aspects of thetechnology may be thought of as “products” or “articles of manufacture”typically in the form of machine (or processor) executable code and/orassociated data that is carried on or embodied in a type of machinereadable medium. Machine-executable code can be stored on an electronicstorage unit, such as memory (e.g., read-only memory, random-accessmemory, flash memory) or a hard disk. “Storage” type media can includeany or all of the tangible memory of the computers, processors or thelike, or associated modules thereof, such as various semiconductormemories, tape drives, disk drives and the like, which may providenon-transitory storage at any time for the software programming. All orportions of the software may at times be communicated through theInternet or various other telecommunication networks. Suchcommunications, for example, may enable loading of the software from onecomputer or processor into another, for example, from a managementserver or host computer into the computer platform of an applicationserver. Thus, another type of media that may bear the software elementsincludes optical, electrical and electromagnetic waves, such as usedacross physical interfaces between local devices, through wired andoptical landline networks and over various air-links. The physicalelements that carry such waves, such as wired or wireless links, opticallinks or the like, also may be considered as media bearing the software.As used herein, unless restricted to non-transitory, tangible “storage”media, terms such as computer or machine “readable medium” refer to anymedium that participates in providing instructions to a processor forexecution.

Hence, a machine readable medium, such as computer-executable code, maytake many forms, including but not limited to, a tangible storagemedium, a carrier wave medium or physical transmission medium.Non-volatile storage media include, for example, optical or magneticdisks, such as any of the storage devices in any computer(s) or thelike, such as may be used to implement the databases, etc. shown in thedrawings. Volatile storage media include dynamic memory, such as mainmemory of such a computer platform. Tangible transmission media includecoaxial cables; copper wire and fiber optics, including the wires thatcomprise a bus within a computer system. Carrier-wave transmission mediamay take the form of electric or electromagnetic signals, or acoustic orlight waves such as those generated during radio frequency (RF) andinfrared (IR) data communications. Common forms of computer-readablemedia therefore include for example: a floppy disk, a flexible disk,hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD orDVD-ROM, any other optical medium, punch cards paper tape, any otherphysical storage medium with patterns of holes, a RAM, a ROM, a PROM andEPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wavetransporting data or instructions, cables or links transporting such acarrier wave, or any other medium from which a computer may readprogramming code and/or data. Many of these forms of computer readablemedia may be involved in carrying one or more sequences of one or moreinstructions to a processor for execution.

The computer system 701 can include or be in communication with anelectronic display 735 that comprises a user interface (UI) 740 forproviding, for example, information regarding the manufacturing of thethermoelectric unit. Examples of UI's include, without limitation, agraphical user interface (GUI) and web-based user interface.

Methods and systems of the present disclosure can be implemented by wayof one or more algorithms. An algorithm can be implemented by way ofsoftware upon execution by the central processing unit 705.

While preferred embodiments of the present invention have been shown anddescribed herein, it will be obvious to those skilled in the art thatsuch embodiments are provided by way of example only. It is not intendedthat the invention be limited by the specific examples provided withinthe specification. While the invention has been described with referenceto the aforementioned specification, the descriptions and illustrationsof the embodiments herein are not meant to be construed in a limitingsense. Numerous variations, changes, and substitutions will now occur tothose skilled in the art without departing from the invention.Furthermore, it shall be understood that all aspects of the inventionare not limited to the specific depictions, configurations or relativeproportions set forth herein which depend upon a variety of conditionsand variables. It should be understood that various alternatives to theembodiments of the invention described herein may be employed inpracticing the invention. It is therefore contemplated that theinvention shall also cover any such alternatives, modifications,variations or equivalents. It is intended that the following claimsdefine the scope of the invention and that methods and structures withinthe scope of these claims and their equivalents be covered thereby.

1. (canceled)
 2. A system for generating health alerts, comprising: (a)a plurality of health sensors for collecting health measurements from ahuman subject; (b) a visual code for retrieving configurationinformation; (c) an application that is executable via a computingdevice that is configured to cause the plurality of health sensors to beautomatically paired to the computing device using the configurationinformation from the visual code, thereby establishing wirelesscommunication between the computing device and each of the plurality ofhealth sensors, wherein the wireless communication is configured toprovide the health measurements to the computing device; (d) a machinelearning unit to process the health measurements, wherein the machinelearning unit comprises one or more machine learning algorithms trainedat least in part on a plurality of previous health measurements thatresulted in true alerts, wherein a true alert is an alert associatedwith a deviation from a baseline health measurement.
 3. The system ofclaim 2, further comprising (e) an alerting unit configured to generateone or more alerts responsive to processing the health measurements bythe machine learning unit.
 4. The system of claim 2, wherein the visualcode is a quick response (QR) code or bar code.
 5. The system of claim2, wherein causing the plurality of health sensors to be automaticallypaired to the computing device comprises selecting, from a database ofpre-defined pairing procedures, a pairing procedure for each healthsensor.
 6. The system of claim 2, wherein causing the plurality ofhealth sensors to be automatically paired to the computing devicecomprises obtaining a universally unique identifier for each of thehealth sensors in the unique combination and using the universallyunique identifiers to scan and identify the health sensors.
 7. Thesystem of claim 2, wherein the health measurements are taken by thehuman subject.
 8. The system of claim 7, wherein the computing deviceprovides instructions for the patient about how to take the healthmeasurements.
 9. The system of claim 8, wherein the instructions aretextual, audible, pictorial, animated, or a combination thereof.
 10. Thesystem of claim 8, wherein the instructions comprise an order in whichto take measurements with the plurality of health sensors.
 11. Thesystem of claim 2, wherein the set of health sensors comprises a bloodpressure device, a position sensor, a heart rate monitor, a pulseoximeter.
 12. The system of claim 2, wherein the application isconfigured to determine whether the health measurements are valid orinvalid.
 13. The system of claim 2, wherein the computing device and ahealth sensor of the plurality of health sensors establish acryptographically secure connection.
 14. The system of claim 2, whereinthe device transmits control signals to a health sensor of the pluralityof health sensors responsive to one or more physical attributes of thesensor or of the subject.
 15. The system of claim 14, wherein a physicalattribute of the one or more physical attributes is an applied weight.16. The system of claim 14, wherein a physical attribute of the one ormore physical attributes is a position.
 17. The system of claim 13,wherein a sensor of the plurality of health sensors automaticallycollects health measurements.
 18. The system of claim 2, wherein thecomputing device comprises processing logic for requesting data from ahealth sensor of the one or more health sensors.
 19. The system of claim2, wherein the data relates to whether the health sensor is being usedcorrectly.
 20. The system of claim 2, wherein the data relates towhether the health sensor is in a communication range.
 21. The system ofclaim 2, wherein a machine learning algorithm of the one or more machinelearning algorithms is trained on data from a population but conditionedon data from the subject.